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Automating Elimination of Duplicate Addresses 


By Mike Harris 

A NUMBER OF techniques for eliminating duplicate 
records - usually address records in mailing list files - 
have been published in The FileMaker Report over the 
years. In addition, the Elk Horn Library includes an 
Application Note by Joe Kroeger on the subject 
("Purging Duplicate Addresses”) and Claris Technical 
Support has a three-page Technical Brief (“Auto¬ 
deleting and Omitting Duplicate Records”) showing 
three different methods. All of this material is worth¬ 
while and should be part of your FileMaker tool kit. 

The FileMaker duplicate Find function is invoked 
by placing an exclamation point (“!”) in the field for 
which dups are to be found. The basic problem in 
FileMaker dup elimination is that this Find collects, 
logically enough, all the dup records, leaving the task 
of separating the keepers from those records to be 
deleted. When each record must be examined individ¬ 
ually to decide which to retain and which to ditch, this 
is appropriate. But, when you simply want to retain 


one copy of a group of duplicates and automatically 
delete the rest, the duplicate Find function is a pain. 

What has been missing in most of these approaches 
is the one thing most users thought they wanted when 
they asked for a duplication eliminator: a way to find 
duplicates and automatically eliminate all but one 
record from each group of duplicates. The trick de¬ 
scribed in this article accomplishes this for those times 
when examination of each duplicate record before 
deletion is not required. One of the Claris methods 
does this as well. The difference between the Claris 
technique and that described in this article is that the 
Claris trick is less flexible about letting you determine 
which record among the duplicates is retained. (For 
details on some of the difference see issue #35 of The 
FileMaker Report, “Equation Du Jour: Group Sequence 
Numbers”.) 

Group Sequence Numbers 

The Claris trick and ours both depend on number¬ 
ing the records within each group of duplicates. The 
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Warning 


Be warned all ye who 
pass these portals: the 
technique described in 
this article uses 
UNDOCUMENTED 
FEATURES. Undocu¬ 
mented features are 
those things a program 
does that the publisher 
doesn't describe in their 
documentation. Trans¬ 
lation: Claris may feel 
free to change File¬ 
Maker so the technique 
in this article won't work 
any more, no apologies 
forthcoming. 
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result is that within any dup group only 
one record is numbered “1”, no matter 
how many duplicate records the group 
contains. By deleting every record except 
those with the sequence number “1”, one 
copy of each duplicate group is retained 
and all the others deleted. 

The Claris Tech Support method of 
numbering groups has been available for a 
couple of years. See box: “To Number the 
Records in a Database By Category”. Their 
technique has the advantages that is does 
not depend on undocumented features 
and it works in FileMaker II. It has the 
disadvantage that it numbers records in 
the order in which they were entered into 
the file. While it is possible to sort records, 
import them into a clone and thereby 
change the native order, it is a bother. The 
technique described below numbers 
records in the order of the current sort, 
which can then be changed as needed. 

This is useful in address dup elimina¬ 
tion because we may have a criteria by 
which we want to select the records to be 
retained. For instance, we may want the 
latest record in each dup group saved. Or, 
we may want the record retained which 
contains the most information. An appro¬ 


priate Sort determines which record from 
a group of dups is kept. 

To Begin ... 

We require the ability of FileMaker Pro 
to convert summary fields into calculation 
fields. Define a summary field as a run¬ 
ning count of any field which has data in 
every record. We will use Last Name in 
our example. 

Sequence = {summary} 

Count of Last Name (running) 

Convert this summary field into a 
record-based calculation. We do this so 
we can use the summary data in calcula¬ 
tions together with ordinary data fields. 
The “Summary” function takes the gener¬ 
al form: 

Calculation Field = (numeric result} 
Summary(Summary Field, Break Field) 

We will use a field called Record Num¬ 
ber as the “Break Field”, although any 
field which is unique to every record could 
be used (see box: “Fields To Live By”). 

The Break Field tells FileMaker which 
groups of records to summarize to get the 
summary-calculation field value. This is 


Neat Solutions Help 

A perennial and nagging problem with address files is the difficulty of identifying 
and eliminating duplicate addresses. Dups arrive from a variety of sources and cause 
problems if not eliminated. Multiple mailings to a given address waste postage; 
status information will be incorrect if scattered over multiple records; and so forth. 
In the past we have had to use only semi-automatic methods for purging such dups. 
This article, however, presents a fully automated method. It will not be useful in all 
situations, but certainly adds a powerful productivity tool in the right circumstanc¬ 
es. It is going to save us a lot of time. 

-Joe Kroeger 
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To Number the Records in a Database By Category 

State CA John 1 State HI E 


John 

1 

State HI 

Bill 

Larry 

2 


Keith 

Mark 

3 


Mary 

Mike 

4 

State NY 

Jan 

Mike 

5 

State OR 

Jim 

Tom 


Where the KEY FIELD refers to the field that is the basis of the sort/sub-summary, 
define the following fields. In the above sample report. State is the KEY FIELD. Note 
"A" means “space”. 

Field Name Field Type Field Definition 


Field Name Field Type 

BLANK calculation (text) 

LOOKUP KEY text 


UPPER calculation (text) 
RECORD COUNT calculation (num) 


number 


LOWER calculation (text) KEY FIELD & Right("(XXX)'' & RECORD COUNT,5) 

COUNTER calculation (num) RECORD COUNT +1 

Once defined, all of these fields will appear on the layout. From the layout you can 
remove all of the fields except SN and RECORD COUNT. 

Find all records and place a 0 in the SN field of the first record. Choose Replace 
from the Edit menu. This will place a 0 in the SN field of all the records. 

Place the cursor in the KEY FIELD of the first record and choose Relookup from 
the Edit menu. This will place a 1 in the RECORD COUNT field of the first record in 
a given category of the KEY FIELD. The second record found in the same category 
will get a 2 and so on. 

The next step is to Sort by the KEY FIELD and the RECORD COUNT field. With a 
Subsummary when sorted by KEY FIELD, all the records will be numbered starting at 
number 1 for each new category. 

Copyright 1991 Claris Corporation 


Lookup KEY FIELD in the current database when 
KEY FIELD matches KEY FIELD; when there is no 
match, Do Not Copy 
KEY FIELD & 1000 

lf(LOOKUP KEY & BLANK= "a",1,SN) 

auto enter 1; Lookup COUNTER in the current 

database when UPPER matches LOWER; when 

there is no match, Copy Next Lower 

KEY FIELD & RightC'OOOO" & RECORD COUNT,5) 

RECORD COUNT +1 


Claris Tech Support 
provides a cookbook 
description of number¬ 
ing records by groups. 
Records are numbered 
in the order in which 
they were originally 
entered into the file. 
Based on a lookup 
technique, it works with 
FileMaker II and does 
not depend on features 
that may be changed in 
future versions of Pro. 
The instructions are 
written for FileMaker II 
but apply to Pro with 
minor differences in 
names of menu items 
and dialog text. The 
Claris instructions are 
reproduced in the box 
to the left. 

Aj-'G o 


an essential specification to get meaning¬ 
ful summary-calculation fields. In this 
case, we need a “Break Field” with a 
unique value in each record. In short, our 
summary “group” consists of one record 
in each group: the number of groups = 
number of records in the file. The result is 
to number each record in order of the 
current sort. (If the Summary were not 
“running”, all records would contain the 


number “1” in this field.) See Figure 2 for 
the results of these and the following 
related calculations. 

Some precautions are required in han¬ 
dling Record Number fields. To insure 
that each “group” of records contain only 
one record. Record Number must have a 
different value in every record. Generally, 
its value is determined at the creation of 
each new record. That is, it is originally 


ih I 
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defined as an auto-entered serially-num¬ 
bered field. In files without this field, the 
Record Number can be created and filled 
from a text file of serial numbers with the 
Update function. 

When records are imported, auto-enter 
serial number fields like Record Number 
are left blank if the source file does not use 
a record number field. If the source file 
(either FileMaker or text) has serial num¬ 
bers, they will be imported and the field 
not left blank; but then there is a problem 
of non-unique serials. Remember this and 
take appropriate precautions if Record 
Number is being used for some critical 
purpose like that described here. Before 
doing any dup elimination work, it is 
strongly suggested that you (a) Find in the 
Record Number field for empty occur¬ 
rences (Find =) and (b) Find dups in the 
Record Number field (Find!) and resolve 
any records so located. 

The specific summary-calculation 
equation we will use is: 


Other Ways... 

The “Purging Duplicate Addresses” App Note discusses the 
elimination of duplicate address records when new addresses 
are imported into an existing file. This is very valuable but 
covers only one way in which duplicates might be generated. 
The technique described isolates the new imported addresses 
which duplicate existing records so that the duplicates may be 
eliminated in bulk or examined one at a time for deletion. 

In “Auto-deleting and Omitting Duplicate Records” Claris 
Tech Support considers three methods of dup elimination. The 
first 2 ways print labels without printing or deleting duplicate 
records. The second of these works with mail merge. 

The third method is based on the second and allows auto¬ 
matic deletion of dups. It does not, however, allow easy ways to 
use a Sort to help determine which of the dups is retained. 



Record Sequence = {numeric result) 
Summary(Sequence, Record Number) 

We also need: 

Record Sequence Calc = {numeric result) 
Record Sequence 

This last equation is required to fool 
FileMaker into allowing the next equation 
(later), which summarizes a calculation 
field (using a regular Summary field) 
using the Summary function. Feel free to 
be confused on this point; these relation¬ 
ships become much more clear as you use 
them. This second equation was not re¬ 
quired in the first release of FileMaker Pro 
but is needed in Pro v2. Claris was con¬ 
cerned that certain kinds of circular defi¬ 
nitions might occur and decided to make 
this impossible by taking away this “un¬ 
documented feature”. They did not have 
time to make FileMaker refuse a new 
calculation field (Record Sequence Calc) 
equal to the old (forbidden) field (Record 
Sequence). The next version of Pro may 
be ‘smarter’ than this and the tricks de¬ 
scribed here won’t work. (We are agitating 
for a substitute way to do group sequence 
numbers if this way is taken from us.) 

We must now get sequence numbers 
within groups of duplicate records. First 
do a Find for duplicates using the “!” 
symbol in a field which effectively identi¬ 
fies duplicate records. “Match Code” will 
likely be such a field. Remember that 
FileMaker does a duplicate find such that 
all the records in a group of duplicates are 
put in the found set, not just the dupli¬ 
cates after the first example of a record. 
Any record with a Match Code that only 
occurs once is, of course, not put in the 
found set. 
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The Sort: A Critical Step 

We will Sort using Match Code (see 
box: “Fields To Live By”). Sort by this 
field to put all duplicates together in 
associated groups. The Sort may also 
include fields which place the record to be 
retained at the beginning of the duplicate 
group. If you want to retain the last record 
entered in the group then specify the 
second field in the Sort as, say, Entry Date 
(descending Sort order). After the Sort we 


would have all records arranged into 
groups of duplicates with the newest 
record occurring first in each group. See 
Figure 1. We need one more field to be 
specified in the Sort: our unique-to-every- 
record field. Record Number. If this field 
is not included in the sort, the summary- 
calculation functions will not calculate, 
bringing our set of linked “domino” equa¬ 
tions to naught. 

Next we now need to know the Record 


'Zjs ! 

AS! ->4 2^ ■2- /CcIk-44/^ 
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Fields To Live By 

Every address file in FileMaker should have three fields without fail: Record Number (or Entry Record 
Number), Entry Date and Match Code (or Name Code). These fields are required for some essential tricks 
which you don’t want to do without. They are discussed briefly below. 

The creation of every FileMaker file should start with a Record Number field. The Record Number (or 
some other unique field) is required for self lookups and other basic FileMaker tricks. It should be defined as 
an auto-enter, numeric, serialized, unique field. 

The Entry Date field is valuable in disaster recovery and helps determine which records are most useful 
when editing records from files. It should be defined as a field with auto-enter of today’s date. With the 
advent of FileMaker Pro, a couple of other valuable functions are available. It is now possible to time stamp 
as well as date each record during its creation. Also, Pro allows recording the date of the last change to a 
record. Consider all of these valuable fields at the beginning of the creation of each address file. 

Match Code fields are used to identify duplicates in address files. They may have been first used in maga¬ 
zine subscription databases, but are now routine for any serious address file. Match Code fields always in¬ 
volve tradeoffs, usually between falsely identifying records as duplicates and failing to find duplicates. It is 
not usually possible to get a fool proof Match Code. Rather it is a question of which errors you can accept 
most easily. Of course, more than one Match Code can be defined in any given file. Using duplication elimi¬ 
nation procedures more than once on a file using a different Match Code each time may produce better 
results than relying on one code. 

A typical match code takes pieces of two (or more) address fields. The trick is to decide how and what to 
use. A simple example follows. Most regularly used Match Codes are more complex, to handle cases like an 
empty Address Two field. 

Match Code = Left(Last Name,3) & Left(Address Two,3) & ZIP {Text Result} 

Sample Address: Sample Match Code: 

Mike Harris HARPOB95063 

Watertechnics 

POB 2307 

Santa Cruz, CA 95063 
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Sequence number of the first record in 
each group, and then do some simple 
arithmetic. Define the following fields: 

GroupMin = {summary} 

Minimum of Record Sequence Calc 


Note 


See The FileMaker 
Report, issue 35, page 
14, for another 
description of this 
method of calculating 
group sequence 
numbers. 


Group Seq Calc = 

Record Sequence - GroupMinCalc +1 

Eliminating duplicates is now easy. 
Sort as in Figure 1, Find records with 
GroupSeqCalc values greater then one 
and delete them. 


GroupMinCalc = {numeric result} 

Summary(GroupMin,Match Code) 

The Break Field in GroupMinCalc is 
Match Code, meaning we have obtained 
the lowest Record Sequence number for 
each group of Match Code duplicates. We 
may now calculate the group sequence 
number (Group Seq Calc) with simple 
arithmetic. Figure 2 shows how these 
fields work together to produce the de¬ 
sired result with a first group of records 
having eight dups and a second having 
five dups. 


Recapitulation 

In outline, after Finding all duplicates, 
this is how the process automatically 
eliminates them: 

• Sort the found dup set of records into 
groups of duplicates based on the most 
discriminating field (usually Match Code) 
we can define for recognizing duplicate 
records. 

• In the process of the Sort, a Summary 
field gives every record a Sequence num¬ 
ber; this Summary field value is converted 
into a record-based calculation in the field 
Record Sequence and avoids FileMaker 
Pro v2’s protection against circular argu¬ 
ments by redefining Record Sequence as 
Record Sequence Calc. 

• Calculates the first Sequence number 
value in each group of duplicate records 
using the Summary field Minimum func¬ 
tion and converts this value into a record- 
based calculation in GroupMinCalc. 

• Numbers records within groups (the 
Group Seq Calc field) by comparing the 
Sequence number of the first record in 
each group of duplicates with the 
Sequence number of each record. 


Figure 1 
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• Delete every record in a duplicate 
group except the first; that is, delete all 
records whose Group Seq Calc is greater 
than“l”. 

Considerations 

There are potential problems with the 
purely automatic of elimination of dup¬ 
licates, primarily that it bypasses any 
human examination of the best record(s) 
to be retained. In most situations, dupli¬ 
cate records are seldom exactiy identical. 

In any given group of “duplicates”, some 
records may contain more information 
than others and some may be more accu¬ 
rate. It is also common that the best final 
record is obtained by combining informa¬ 
tion from two or more of the original 
“duplicates”. There may be no good alter¬ 
native to record-by-record examination of 
at least some of the duplicates, depending 
on their history, using one of the appro¬ 
priate techniques fi-om Joe Kroeger’s 
Application Note or the Claris Technical 
Brief. 

Still, it is possible to use the dup elimi¬ 
nation approach in this article yet protect 
yourself against some kinds of data loss. 
For instance, records are more likely to be 
identical if they contain the same total 
number of characters (in all their fields). 
To avoid throwing away “duplicates” 
which might contain valuable informa¬ 
tion, you can count the number of charac¬ 
ters in the fields of a record and add this 
number to the Match Code. Then only 
records which met the criteria of the 
original Match Code calculation and have 
the same number of total characters will 
be put into dup groups. After using this 
article’s automatic elimination for those 
records, you can revert to the original 
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Match Code formula and examine records 
one at a time for finer discriminations 
about what really constitutes a duplicate 
record. 

The additional calculation for character 
counts might look like this: 

Total Characters = {numeric result} 
Count(First Name) + Count(Last Name) 
+ Count(Address One) + Count 
(Address Two) + Count(City) + 
Count(State) + Count(ZIP) 


Note 


See The FileMaker 
Report, issue 37, page 
13, for a suggested list 
of address fields for 
FileMaker address files. 


The new Match Code formula would 
then be: 


Match Code = {Text Result} 

Left(Last Name,3) & Left(Address Two, 
2) & ZIP & Total Characters 
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Catalog Publishing With FileMaker 




Part 2 


In Part 1 of this article 
(in issue 37), Mike 
discussed the basic 
tricks involved in 
developing a file that 
prints properly as a 
double-sided catalog. In 
Part 2 presented here 
he extends the concepts 
by showing how to 
emphasize particular 
records with various 
special effects. - JK 


By Mike Harris 

In many catalogs it is desirable to 
emphasize some items. There may be an 
overstock or a discontinued item, we 
might want to promote a “loss leader” or 
bring attention to a particularly popular 
product. This is often done by changing 
the presentation of that particular catalog 
entry, perhaps by adding an illustration, 
using larger type or a border. These are 
perfect applications for data-driven lay¬ 
outs - particularly because the items to be 
emphasized with special effects can be 
changed quickly with a simple data field 
change. This allows you to change specials 
from one edition of the catalog to the 
next, or even, in the ultimate case, to 
customize a catalog’s specials for every 
group (or even every person!) to which it 
is sent. 

You might consider emphasizing an 
entry with a larger, special font for the 
Composer field. Adding two new com¬ 
poser name calculation fields, a selection 
field and modifying the existing right and 
left hand Composer fields does the trick. 
Start with a numeric BoldComposer 
Select field. Then: 

ComposerCalcBoldL = {text result} 

lf( BoldComposer Select = 1 and Page 
Side = "L", Composer,"") 

ComposerCaIcBoldR = {text result) 

lf( BoldComposer Select = 1 and Page 
Side = “R", Composer,"") 


ComposerCalcL = {text result) 

lf(BoldComposer Select <1 and Page 

Side = "L", Composer,"") 

ComposerCalcR = {text result) 

lf(BoldComposer Select <1 and Page 
Side = "R", Composer,"") 

Now place both left and right Com- 
poserCalcBold fields on the layout. Since 
these are separate fields, they can be given 
entirely different fonts, font sizes and 
styles. If these two new fields are format¬ 
ted larger than the original Composer 
fields, just make the enclosing Part larger. 
Since the slide feature is set for both slid¬ 
ing of objects and parts, the extra space 
will be removed on records without the 

Figure 7 
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Figure 8 


bold composer option selected. See Figure 
7 for an example of using this technique. 

If the reader has followed the calcu¬ 
lation tricks so far, it is clear how to gener¬ 
ate a field for special text overlays like a 
“Sold Out” line. Define a simple text field 
for this purpose and put it in an appropri¬ 
ate place on the layout. When you enter 
text into this field the text appears, other¬ 
wise the field is invisible. If you use bold 
letters you get an effect common in some 
types of mail order catalog: a bold overlay 
of existing entry text. See Figure 8. 

Overlays set off by a white area, to 
avoid the jumble of letters written directly 
over each other or to completely cover the 
original entry, require picture rather than 
text fields. The reason is that while a File- 


"" in an equation 
represents two quote 
marks with nothing in 
between; this is File¬ 
Maker short-hand for 
"nothing at all" in text 
calculations 


Data-Driven Illustrations 

Calculations cannot have picture results in FileMaker - we need to use lookups. For illustrations stored in 
picture fields in each record we need self-lookups. Self lookups are the same as regular lookups except that 
the source and destination files are the same file. In our case we lookup from the same record as well as the 
same file since we are storing illustrations in picture fields in the same records with our other music infor¬ 
mation. Lookups require two fields that match. In this situation we need three new calculated fields: 

LeftRecorcfNum = iffPage Side = "L",Record Number & "L","") {text result} 

RightRecordNum = if(Page Side = "R",Record Number & "R","”) {text result) 

RecordMatch = LRecordNum & RRecordNum {text result) 

These fields work as follows: 


Left-Hand Record 

LeftRecordNum = Record NumberL 
RightRecordNum = (blank) 
RecordMatch = Record NumberL 


Right-Hand Record 
LeftRecordNum = (blank) 
RightRecordNum = Record NumberR 
RecordMatch = Record NumberR 


Our left and right picture fields then result from the following lookups: 

Picture L Picture: 

Lookup "Picture" in "Melodies" when LRecordNumber matches "RecordMatch" If no match: "Don't copy" 
Picture R Picture: 

Lookup: "Picture" in "Melodies" when RRecordNumber matches "RecordMatch" If no match: "Don't copy" 
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Note 


FileMaker Pro does not 
allow picture fields to 
be automatically cleared 
when lookups go from 
match to no-match. This 
is a change we hope 
Claris considers for the 
next version. 


Maker field can be formatted for an 
opaque white fill, the white rectangle of 
such a field then appears on all records, 
whether or not the field has a calculated 
text value. We require that our data- 
driven fields completely disappear when 
containing no values. 

Of course, picture fields are also re¬ 
quired for illustrations and special bor¬ 
ders. FileMaker equations cannot have 
picture results, so data-driven pictures 
must be looked up instead of directly 
calculated. Control of the picture lookup 
is through calculated match codes (see the 
box “Data-Driven Pictures”). We would 
place looked-up picture field illustrations 
below the text fields of the layout. When 
we apply the slide option to the picture 
fields, there is no change is the appearance 
of records without illustrations. Where 
illustrations exist space is allowed. See 
Figure 9 for the layout with picture fields 


Figure 9 
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and Figure 11 for a catalog page with 
illustrations. • 

A convenient way to develop illustra¬ 
tion options is to create a control panel of 
check boxes. This allows you to go 
through each record and quickly select 
any special effects you might want to 
invoke. If the check boxes and their labels 
are formatted as non-printing objects, the 
control panel may be placed on the regu¬ 
lar layout for catalog printing without 
messing up the printed page. In browse 
mode this means you can see the effects as 
you select them, with the minor exception 
that sliding effects do not appear. Howev¬ 
er, of course, you can see the fully sliding 
result of your choices in Preview mode. 

To create an illustration check box start 
with a new field called Picture Select. 

After naming the field and choosing the 
text field type, click on the Options button 
and select “Define Value List”. Enter the 
single number “1” in the value list win¬ 
dow. This allows you to format the 
Picture Select field as a check box. Place 
this field, and any similar fields you may 
create such as “Border Select”, on the 
catalog layout as “non-printing objects” 
(with the field selected in Layout mode 
open the Arrange menu, choose “Slide 
Objects...” and select “Do not print the 
selected objects.”). This allows you to 
browse records and select the appearance 
of each record in the catalog one at a time 
(see lower right of layout Figure 9). 

To finish, modify the Record Match 
formula (see Box “Data-Driven Illustra¬ 
tions”) to: 

RecordMatch = {text result} 

lf( Picture Select = 1, LRecordNum & 
RRecordNum,"") 
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Now a catalog entry gets an illustration 
only when the Picture Select box is 
checked (if the record contains an illustra¬ 
tion in its Picture field of course). 

Other Graphics 

For the purposes of this article I con¬ 
sider an “illustration” to be a figure which 
applies to only one record, and which is 
stored with other data fields in that 
record. The lookup which finds the illus¬ 
tration when it is desired in the catalog 
print-out is a self-lookup. In the case of 
borders and figures which can apply to 
many records, we have a separate file with 
picture fields which is accessed through a 
regular file-to-file look up. 

The equations and lookups required 
for graphic elements which can be used in 
any catalog entry are nearly identical to 
those described for illustrations. In fact, 
they are somewhat simpler. For a border, 
for instance, we need a new FileMaker 
look-up file to hold the border drawing in 
a picture field, two new calculation fields 
and two new picture fields. The new file 
will be “GraphicsLU” and contain 2 fields: 
Graphic, a picture field, and Match, a text 
field. 

The new calculations (in the original 
catalog file) are: 

LRecord Border = {text result) 

If (Page Side = "L" and Border Select = 
1,"border","") 

RRecord Border = (text result) 

If (Page Side = "R" and Border Select = 
1," border","") 

The new picture fields are: 


Border L Picture Lookup: 

"Graphic" in "GraphicLU" when 
"LRecord Border" matches "Match" If 
no match: Don't copy 

Border R Picture Lookup: 

"Graphic" in "GraphicLU" when 
"RRecord Border" matches "Match" If 
no match: Don't copy 


Note 


When picture fields are 
required for an effect, 
lookups rather than 
calculations alone are 
required. The only 
exception is when a font 
itself consists of illustra¬ 
tions rather than 
pictures. 


Figure 10 
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=- If you want to have several border 

g [ [ ^ types, store them in GraphicLU with 

^ individual names entered in the Match 

field. Then create a new text field, Border 
Type, and change the equations above by 
substituting Border Type for “border”. 
Similarly, we want to have an accent 
graphics field for graphics such as “ka- 
pow” clouds. Create a set of fields and 
lookups as described immediately above 
for accent pictures. Make the accent se¬ 
lectable with an Accent Type which works 
the same way as Border Type. 

Figure 10 shows how all these control 
options might be arranged on a layout in 


Figure 11 
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browse mode. Remember all the control 
panel elements would be non-printing 
objects and so not appear in the final 
catalog print out. (When placed below 
other objects in the layout, non-printing 
objects do prevent proper slide up. This 
layout is not suitable for final catalog 
pages.) 

Figure 11 shows the entry in Figure 10 
as it would print as part of a catalog page. 

The Ultimate Catalog 

I leave as an exercise for the reader the 
construction of a catalog which generates 
layouts based solely on data. For instance, 
if sales and inventory data are maintained 
with the catalog records, layout changes 
can be triggered by number or dollar 
values of sales, or by low or high invento¬ 
ry. As inventory drops, items could even 
be left out of the catalog entirely, without 
removing a possibly useful record fi'om 
the file. I see no reason why customer 
information - preferences, past purchases 
- could not be used to generate a unique 
catalog for every customer, printed as 
required on a laser printer. Maybe we 
could save some trees by sending much 
smaller, more targeted catalogs instead of 
having to “send the whole phone book” to 
everyone. 
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Errata: Elapsed Time Corrections 


By Sheila Kliewer and Joe Kroeger 

In the article “Calculating Elapsed 
Times” in The FileMaker Report, issue 36, 
the equations shown work for a limited 
range of elapsed times only. An alert 
reader reported that in testing the tem¬ 
plate, elapsed times longer than about 3 or 
4 years generated obviously incorrect 
results, sometimes with negative numbers! 
Intervals in the range of hours or days or a 
few months work fine. 

Hours Limitation 

We checked with Claris Tech Support 
and it turns out that FileMaker Pro is 
limited to 32,767 hours (2^5-1) when 
calculating times and won’t handle larger 
numbers in the hours position of a time 
expression. To get around this limitation, 
we can extract the elapsed days prior to 
using the time function to calculate the 
final partial day’s elapsed hours, minutes, 
and seconds. (Alternatively, the limitation 
can be ignored if the time spans of con¬ 
cern are always less than a year or two.) 

Try using the following calculations in 
place of eSecondsTotal, eDayPart, and 
eTimePart shown in the previous article. 

eSecondsTotal = {numeric result} 

If (Stop Date - Start Date > 1, ((Stop 
Date - Start Date) - 1) * 86400 + Start 
Seconds + Stop Day eSeconds, Stop 
Day eSeconds - Start Seconds) 

eDay Part = {numeric result) 

Int (eSeconds Total / 86400) 


eTime Part = {time} 

Time (00,00, (eSeconds Total - 
(eDay Part * 86400))) 


t t t 


♦ t 1 

3 




Fix Start/Stop Hour 24 Time 

In the course of our conversations with 
Claris Tech Support, they pointed out that 
we also neglected to account for 12:00 am 
(midnight) being zero hours and 12:00 
pm (noon) being 12 hours in our previous 
“Hour 24” calculations. The old calcu¬ 
lations simply added 12 to the hour if 
Start am\pm = "pm" which thus set mid¬ 
night at 12 and noon at 24. To correct the 
oversight, replace the 24-hour time calcu¬ 
lations with these new versions: 

Start Hour 24 = {numeric result} 

If (Start am\pm = “PM" and Hour (Start 
Time) = 12, 12, If (Start am\pm = "AM" 
and Hour (Start Time) = 12, 0, If (Start 
am\pm = "PM", Start Hour 12 + 12, 
Start Hour 12))) 

And likewise: 


Lesson 


When designing a new 
set of calculations, be 
sure to test them over a 
wide and extensive set 
of trial data (!). 


Stop Hour 24 = {numeric result} 

If (Stop am\pm = "PM” and Hour (Stop 
Time) = 12, 12, If (Stop am\pm = "AM" 
and Hour (Stop Time) = 12, 0, If (Stop 
am\pm = "PM", Stop Hour 12 + 12, 
Stop Hour 12))) 

These revised calculations have been 
entered into the elapsed time template to 
bring it up to date. 
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By Mike & Joe 
The Answer Guys 


Q & A: Summarize Sales From Repeating Fields 


Q & A Motto 


"If it can't be done 
with FileMaker 
it's not worth doing!" 



Is it possible to count or summarize 
entries in the repeating fields of 


several records and automatically enter 
the results into summary fields as shown 


in Figure 1? 


-LA. 


Figure 1 

rec I 



^ FileMaker can handle your problem 
with counters. “Counters” are 
category numbers associated with repeat¬ 
ing field items which can be counted in 
each record and summarized for reports. 
The technique is very powerful but is also 
limited in practice to a maximum of a few 
dozen items (or categories of items). The 
sensible way to 
implement counters 
is by having a sepa¬ 
rate file to store 
information about 
the parts to be en¬ 
tered into repeating 
fields and to look up all part information 
(including counters) from a part number 
during data entry. 

Let’s start with a Parts file. Usually in 
such a file you want fields such as Part 
Number, Description, Price and perhaps 
Cost. To use counters to identify into 
what category each item belongs, create an 


Summary 

_4 tomatoes 
apples 

j_ oranges 


additional number field for each possible 
category. In your example, a “category” is 
simply the fruit or vegetable in question. 
(Keep in mind, however, that some uses 
for counters put many parts into the same 
category, depending on what you are 
trying to accomplish. For instance, in a 
small antique mall with stalls belonging to 
several vendors, the “category” a counter 
designates might be the name of the ven¬ 
dor to whom the item belongs.) Your 
example requires three counter fields: 
Tomato, Apple and Orange. 

As each part is entered into the Parts 
file, place a “1” in the appropriate counter 
for each part and leave the other counter 
fields empty. (In situations where a part 
may fall into more than one category a “ 1” 
would be placed into each applicable 
counter. Figure 2 shows a View -As-List 
browse mode view of the Part file records. 

Now, we will construct a very simple 
Invoice file, where the work in question 
takes place. We need all the fields created 
in the Parts file, although the names do 
not have to be exactly the same. These 
fields (except Part Number which is the 
basis of the lookup) will be looked up 
from the Parts file as each repeating line is 
filled in, so use the Options button to add 


Figure 2 
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a lookup specification to each field as it is 
created. In addition we need fields to 
calculate how many of each item category 
is entered into a repeating field line. While 
we know that only one part will be entered 
into any given line, we do not know which 
item it will be. So we need calculations in 
each line for each part even though two 
out of three of these calculations will yield 
“0” values. We will use “LT” in these field 
names to abbreviate “Line Total”, which is 
what the calculations tell us; the Line 
Total count of each item. Define these 
fields: 

Quantity {number} 

LTTomato = (numeric result} 

Quantity * Tomato 


Figure 3 shows an appropriate way to 
layout these fields. Figure 4 shows a 
browse mode view of record number 3. 
Notice that the Summary is visible. The 
Summary numbers are also visible when 
viewing each of the first two records and 
always reflect the totals for all (found) 
records, without sorting. One precaution: 
since these counters would normally 
operate in the background, errors can 
occur when part entries are changed. A 
new counter (Tomato, Apple, Orange) 
may be looked up as a “ 1” while the old 
counter remains. To deal with this place a 
“0” in the Parts file counters that were left 
blank. Then during lookup the “0” will 
over-write any stray “ 1 ’s”. 


Figure 3 


LTApple = (numeric result} 

Quantity * Apple 

LTOrange = (numeric result} 

Quantity * Orange 

Now we need to total these counter 
fields for each record. We will use “PT” to 
abbreviate “Page Total” in the field names. 

PTTomato = (numeric result} 

Sum(LTTomato) 



PTApple = 


(numeric result} 


Figure 4 


Sum(LTApple) 

PTOrange = (numeric result} 

Sum(LTOrange) 

For our “Summary” report we use 
three FileMaker summary fields: 

SumTomatoes = Total of PTTomato 

SumApples = Total of PTApple 

SumOranges = Total of PTOrange 
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